「SCMBootCamp in Tokyo 2」に参加してきました！

こんにちは！おおはしりきたけです！

11月19日にオラクル青山センターで行われた「SCMBootCamp in Tokyo 2」に参加してきました！

SCMBootCampとは？

ソフトウェア構成管理(Software Configuration Management) を学ぶ勉強会です。 SCM※1 のキーポイントとなるバージョン管理を「講演」＋「ハンズオン演習」で学習します。 バージョン管理はソフトウェア開発に携わる全ての人に関わるものであり重要ですが、なかなか概念から勉強する場所がありませんでした。 特に最近では分散バージョン管理(DVCS※2 )がメインとなっていますが同様です。 この勉強会ではDVCSの概念、思想、基本操作を講演、ハンズオンで習得してもらえいたいと考えています。 演習では簡単なHTMLファイルをグループで作成してもらいます。

イベントURL：http://kokucheese.com/event/index/18517/

タイムスケジュールは以下で進んでいきす。

第一部 - 講演
9:30 - 10:00    受付
10:00   開会
10:20 - 11:15   基調講演 @flyingfoozy (藤原克則)
11:15 - 11:20   休憩
11:30 - 12:00   Git入門
12:20 - 13:20   お昼休み(運営にてお弁当提供)
第二部 - 演習
13:20 - 14:35   演習1
14:35 - 14:50   休憩
15:10 - 15:50   演習2
16:10 - 16:40   レビュー + 休憩
16:40 - 17:40   演習3
17:40 - 18:00   レビュー + 休憩
18:00 - 18:20   DVCSの次の一歩
18:10 - 18:20   KPT
18:20 - 18:30   閉会
懇親会
19:00 - 21:00   会場にてビアバッシュ

■開会

開始がちょっと遅れましたが、kyon_mmさんによる開会宣言からSCMBootCampが始まりました。

■基調講演

10:20 - 11:15 『分散リポジトリ型時代』のソフトウェア構成管理  @flyingfoozy (藤原克則)さんによる基調講演です。

詳細な資料は、ここに公開されています。

○「構成管理」とは？

おおざっぱにいうのであれば「構成管理」＝「変更履歴管理」＋「品質管理」 『パターンによる構成管理』で言うところの「品質管理」は、 継続的インテグレーション (Continuous Integration: CI) が主眼ラショナル統一プロセスで言うところの「品質管理」は、 障害 (bug) ／要求 (issue) 追跡が主眼。パターンによる構成管理と統一プロセスで、観点が違う。

一般的には「構成管理」≒「変更履歴管理」で考えて問題ない

○構成管理導入のメリット

SCM ツールは、以下の情報を記録します。

• (物理的な) When：何時の作業か？
• (論理的な) When/Where：どの時点の成果を元にした作業か？
• Who：誰の作業か？
• What：どのファイルに対する作業か？
• Why：作業理由は？ ※ 正しくメッセージを記述した場合
• How：どのような作業か？

構成管理の良くある誤解として、一人だからいらないというのは間違い。誰もフォローしてくれないからこそ、構成管理が必要。失敗は次へ進むための重要なファクターとおっしゃっていました。バックアップの履歴記録として、構成管理を使う。実際作業領域のアーカイブは10回超えたら不可能。「実績」記録によるライフログを取ることによって、誰が何行変更したか、どのファイルに更新がかかっているかなのが把握できる。さらに、有効作業量の算出ができる。

半年分のコミットすべてが3分程度で算出できる。これにより、本体は書いてるけどテストかけてないなどの改善活動につながる。

○共同作業における調停

SCM ツールがなくても、同等の事は出来るでしょ？というのは間違い「やってやれなくはない」かもしれませんが、 そこにコストを掛けるのは、単なる労力の無駄使い。

○『分散リポジトリ型』とは？

SCMの世代比較

【第1世代 (SCCS/RCS)】

「履歴データ格納場所」と「作業領域」が隣接いて、NFS でのファイル共有等で、 同一のディスク領域を共有しているため、変更を記録し終わっても開放をし忘れることがあったり、同じ領域で作業するため途中の成果まで入ってしまうこともある。

【第2世代 (CVS/SVN/VSS)】

リポジトリと作業領域が分離した。分離されたことでプライベートワークスペースが実現された。リポジトリにアクセスできないと大幅に機能低下

【第3世代 (Bazaar/Git/Mercurial)】

「リポジトリ」＋「作業領域」は各自で複製を保持するようになった。「リポジトリ」と「作業領域」が隣接したため、「リポジトリ」アクセス不能による機能低下が無くなった(第1世代と同じ)リポジトリが分散しているから分散リポジトリツールという

○履歴データの完結性

ユーザが明示的に指示しない限り、 他のリポジトリとの連携は発生しません。

○リポジトリの連携

よくある批判として平行作業の履歴統合作業が面倒臭い！というのがあるが、「統合作業」の必要性を、 「余計な一手間」と見るか、 「平行開発に必要なコスト」と見るかの視点の差。自動的に完了しないのは第3世代だけの問題ではない。履歴記録で安全が買えるのあれば、安い買い物。作業記録が100個を超えると変更内容とか日付とかで条件指定で抽出して見るようになるので、ログの「汚れ」なんて気になることはない。

※手間はかかるけど、並行開発ができるメリットとして考える！！

○リポジトリ連携の対称性

第3世代では任意の「リポジトリ」が契機となって、 「履歴データ」を転送することが可能になった。転送契機は以下の二つ

• 連携先から、転送契機側に取り込む (pull)
• 転送契機側から、連携先に反映させる (push)

リポジトリ連携が対称性を持つことで、 セキュリティ／ネットワーク的な面での制約に対して、柔軟に対応することが可能。

○小さく初めて大きく育てる

• 利用開始コストが低い
• 機器構成の変更への柔軟な対応
• 私的記録の公開が用意

○分散リポジトリ型の運用

運用方法の紹介

• 『第2世代的な使用』
• 『オフラインサテライトでの作業』
• 『多拠点での平行開発』
• 『特定作業の物理的な隔離』
• 『リモートからの pull 禁止』
• 『品質監視ゲートウェイ』
• 『コミット前レビュー』

それぞれユースケースごとに運用方法が、解説されていました。特に『品質監視ゲートウェイ』はこんな使い方もできるのか！！と目からウロコでした。資料では図解で説明されています。

最後の”第2世代以前の SCM ツールからの移行であれば、 「構成管理が面倒」なのではなく、 「面倒なツールで構成管理していた」ことが実感できて幸せ”という言葉がすごく印象的な言葉でした。

■Git入門

11:30 - 12:00 Git入門

@bleisさんによるGit入門のお話です。

[slideshare id=10226700&doc=scmbcgitforslideshare-111118211807-phpapp02]

以下は私のメモになります。資料では、各オブジェクトが非常にわかりやすく図解されています。図って素晴らしい！

○Gitのリポジトリ

Gitではリポジトリがローカルにある。

手元のリポジトリではコンフリクトすることはない。

○多人数開発

• SVNでは1リポジトリー複数ツリーだけど、Gitでは個人がリポジトリを持つ。
• 共有リポジトリに個人がpush,pullを行う。
• 共有リポジトリは複数ある場合もある（CI用とかステージング用とか）

○Gitのオブジェクト

全てがImmtableで作成されたら破棄されない限り変更されない。

オブジェクトの種類

• Blob
• Tree
• Commit
• （Tag）

○Blobオブジェクト

• ファイルの中身だけを表す
• ファイル名などは Tree オブジェクトが保持
• Tree や Commit をまたいで参照される
• 差分ではなく、スナップショット保存される

○Treeオブジェクト

ディレクトリの構成を表す

• 子ファイル
• 子ディレクトリ

○Commit オブジェクト

• コミット（リビジョンの記録）
  • コミットした人、時間、メッセージ
  • 親コミット
  • ルート Tree …
• 親コミット
  • 通常ひとつ
  • マージした場合、複数
  • 初回コミットにはない
• 親コミットを順にたどることで歴史がわかる

○コミットメッセージ

普通にGitを使うとメッセージは必須！空行はエラーになる。

一行目に概要、二行目を空白、三行目以降に詳細を記述する

○オブジェクトのハッシュ値

• 全てはオブジェクトのSHA-Iハッシュ
• 比較はすべてハッシュで行う
• 世界中で一意性が担保される
• リモートの通信でもハッシュ値のオブジェクトで判断できるので、高速かつ低負荷

○ブランチ

• Commitオブジェクト（ハッシュ値）へのポインタ。ポインタなので作成、削除が高速
• Commit オブジェクトの親コミットをたどることでブランチが表現できる

○ブランチの使い方

最初はmaster

• git branchで作成
• git checkpoutで移動

フィーチャブランチ(トピックブランチ)

• 機能ごとにブランチを切る
• 短期間用のブランチ

rebaseをすると履歴が1本線になる。実はSVNでもできていたことだが、gitのrebaseはいくらでもやり直しができる。

○分散リポジトリの例

• git clone
• リポジトリはバラバラに成長するが、区別できる
• git fetch origin　で変更分だけ取得
• マージする場合は、git pushで変更を通知

■Bazzer入門

12:00 - 12:20 Bazzer入門

wonderful_pandaさんによるBazzer入門

この時間はBazzerとHBに分かれて、セッションを聞くことになり、私はBazzerを聞きました。セッション時間は短かったんですが、資料が公開されています。以下、私のメモです。

○基本用語のお話

ブランチという単語がDVCS毎に違う

bazerでのブランチはリビジョンを積み重ねることで、開発が進んでいきます。この、一連のリビジョンの連なりが ブランチ (名詞)です。

最新のリビジョン(HEAD)はひとつのブランチに対して常にひとつ。

作業コピー 自由度が高いけどわかりにくい

リポジトリ それ自体は何も意味をもたない。単なるフォルダてきなもの Bazzerはブランチに注目して作業をする

○作業フロー

Bazzerは集中型だけでも使える ローカルにも情報を持っているので、履歴の参照などできる

SVNの問題点として、マージが怖い まだコミットしていない状態でマージをしなければならない。変更に失敗できない。

分散型なんだからコミットしたうえできれいにマージしよう

○メインラインについて

そのブランチにとってもっとも重要な経路を、メインライン と呼びます。

bazzerでは基本的にメインラインを見て開発を行う

サブのラインのコミットが汚いなどはあまり気にしない

ただし、メインラインはきれいなコミットをすることを強く求められる

○コミットの粒度

Bazaarには uncommit というコマンドがあり、このコマンドでコミットを最新のものからいくつでも取り消すことができます。

○コミットコメントについて

マージ後のコミットには、ちゃんと変更した内容を書きます。

DVCSとしてのメリットを最大限に活かすのであれば、開発する機能ごとにブランチを分けた方がいいでしょう(フィーチャブランチ)

■演習説明

お昼にお弁当をいただいた後、午後はいよいよ演習の時間です。ここで演習の内容が伝えられました。課題は「DVCSのチートシートを作成する」という内容ですが、チートシートを作成するのが本来の目的ではなく、チートシートを作成していくためにDVCSを使うというのが課題になります。私はGitチームとして参加したので、Gitを使うことになりました。

■演習１

13:20 - 14:35 演習1

演習は3回に分かれています。私たちのチームは私を含めGitの未経験者が多かったため、第1回の演習では、基本コマンドを叩きまくるということにしました。

私たちのチームの講師は神速さん（@sinsoku_listy）でした。

githubを共有リポジトリにして、まずはgit cloneでローカルにリポジトリを作ります。

まずは各々新規のファイルを作成し、git add "ファイル名"を行い、git commitでリポジトリにコミットを行いました。SVNでのcommitはリモートへコミットされますが、Gitでは、ローカルのリポジトリにコミットされることになります。リモートへ反映させる場合は、git pushを行います。

演習１での神速さんのありがたいお言葉「git helpとgit help --all は覚えておいて損はない」

■演習２

15:10 - 15:50 演習2

基本コマンドはある程度覚えたので、次は共通のファイルを修正し、ワザとコンフリクトを起こしながら作業を進めていこうということになりました。

5人で同じファイルを触っているためコンフリクト地獄が発生しました！

上記の画像はgitkというツールです。これで履歴の状態がよくわかります。路線図みたいですよね。。。

gitk --all &で表示されます。

演習２での神速さんのありがたいお言葉「勉強用にgitkを使うのも有効。どんなコマンドで、どう動いたかがわかる。」

■演習３

演習３では、pullではなく、fetchとmergeを使ってみようということになりました。

pullは実際fetchとmergeを行っており、fetchを使うとファイルをダウンロードするだけなので、コンフリクトが派生することがないということでした。

git fetchを行ってから、git merge masterをし最後にpush

その後、git rebaseをやっていただきましたが、現在の私の知識と経験ではrebaseはまだみにつけることはできませんでした。

git add はファイルをオブジェクトにかえる（内部的にBLOBに変える）gitのcommitコマンドは、addした内容でcommitオブジェクトを作るということらしいです。

演習３での神速さんのありがたいお言葉「addは下書きcommitが清書」

演習を体験したことにより、Gitの理解が深まりました。ちょっとした質問にも丁寧に答えていただいた神速さん本当にありがとうございました。

■DVCSの次の一歩

DVCSの次の一歩ということで、Git、Bazzer、Mercurialの次の一歩ということで講師の方々が話をしてくれました。

【Bazzer】

@methaneさんのお話

SVN以外を使いたいということで、Bazzerを使い始めた。

○bzrにしてよかったこと

• SVNを使っている人であれば、教育コストが少ない。
• SVNコマンドとBZRコマンドはほとんど一緒
• 新しいツールの使い方を覚えたくない人にも優しい

○その他の利点

• オフラインでも使える
• ローカルでも使える

○広めるために必要なもの

• 熱意
• 仲間

○おすすめ方針

• まずは使ってみる
• 社内に味方を作る
• 経験値をためる
• 小さいチームで勝手に導入
• 大きいプロジェクトに勝手に導入

【Git】

Gitチームは「Gitのネクストステップに向けてのQ&A」ということで、講師の方々が、事前に集めた質問に答えるといった形式でした。

○bzrやHBに負けないgitのいいところ

• 速度は素晴らしい
• githubがあるので覚えておいて損はない
• gitは自由度が高い。できちゃって怖いところはある

○合わせて使いたいgitとの連携ツール

• RedmineとかのBTS⇒rebaseとの相性がいい
• .filesの管理にgitを使うのはおすすめ
• gitk　歴史をビジュアルに表示できるツール
• マージツールをエディタではなく、ツールを使うgit merge toolというコマンドがある

○テスト環境と本番環境で設定ファイルが異なる場合の管理

ブログのエントリ見てね

【Mercurial】

@flyingfoozyさんによる脱初心者の一歩のお話。

○脱初心者の一歩

MQ (Mercurial Queues)を使う。

○何が嬉しいのか？

• 対象リビジョンの上に、別な変更を重ねられる
• 気分的には「メモ書きトレーシングペーパー」

○どのような時使えるか

ユースケース１：環境依存の差し替え

• 簡易テストではパッチをつけて、本番ではパッチを外すなど環境に応じていろいろ切り替える

ユースケース２：プリコミットマージ

• コミットはレビュアー限定
• レビュー結果によっては再度の修正

■クロージング

最後のクロージングもkyon_mmさんが行いました。kyon_mmさんはSCMBootCampを行うことにより、みんながリリースできることを目指いしているという熱い思いを語っていただきSCMBootCamp in Tokyo 2は終了しました。

私はその後も懇親会、闇LTに参加させていただき楽しい時間を過ごせました。

■最後に

参加する前はDVCSの良さというものが、正直体感できていなかったんですが、今回参加させていただき、ハンズオンでGitに触れたり、実際に使っている方の話を聞くことで、必要なツールであるということが理解できました。素晴らしい会を主催してくれてkyon_mmさん、各DVCSの講師の方々、スタッフの方々、場所を提供してくれたOracleさん、そしてメイドさん。ありがとうございました。